Many public and private communication networks include hierarchical networks of Asynchronous Transfer Mode (ATM) layer equipment (i.e. deployed ATM network nodes). To provide new IP-based multicast services within such networks, it is necessary to enable IP multicasting capabilities within such networks. However, it is often not be feasible or desirable to retrofit IP layer capabilities or new hardware into deployed ATM network nodes of such networks.
ATM is becoming an increasingly important protocol for the mass-market delivery of high-speed IP services. ATM has been adopted as a preferred transport layer for such high-speed IP services. Streaming and broadcast video distribution solutions, which use Internet Group Management Protocol (IGMP) as the control mechanism for dynamically creating connections, are an example of such high-speed IP services. The growing demand for Asymmetric Digital Subscriber Line (ADSL) services, which are supported by ATM networks, is one reason for the importance of ATM and ATM networks. To support high-speed IP services over an ADSL access network, there exists a need for a solution to provide mediation between ATM and IP domains.
ATM Switched Virtual Circuits (SVCs) may be used to dynamically configure point to multipoint connections from a centralised control node. SVCs are normally established between two end devices although techniques also exist for terminating the signalling within the network. These alternate techniques provide the impression that the end user has terminated the signalling where as, the network has terminated it on their behalf. An example of the latter is a Soft Permanent Virtual Circuit (PVC) implementation).
A traditional ATM SVC approach is known to require the exchange of several messages between the network and either of the connection termination points each time a call is established. Through the life of an SVC connection, an ongoing exchange of messages is necessary. The requirement to exchange several messages in order to establish a connection adds to connection set-up latency. Under conditions of correlated connection set-ups (where simultaneous set-up attempts from tens or hundreds or more subscribers arrive in a very short space of time, say 1 second), the demands placed on a microprocessor that is managing the SVC service are high and performance may be less than desirable.
Secondly, the ongoing exchange of messages through the life of an SVC can also lead to significant loads being placed upon the microprocessors supervising the SVCs. Such significant loads occur particularly when there are hundreds of active SVC connections. This additional microprocessor load directly reduces the processing capacity with which the microprocessor would be able to execute additional call set-ups and tear downs.
By nature, IGMP is a dynamic call set-up protocol used within the IP world. In contrast, the community creating ATM standards has defined Switched Virtual Circuits (SVCs) to achieve the same purpose. It would therefore seem logical that an IP Gateway should initiate an ATM SVC towards the end user in response to the end user's request to initiate a multipoint flow. Unfortunately, this approach is not so optimal for a number of reasons. One reason is that many network operators considering IP multicast services have ruled out SVCs in their networks. Another reason is that nearly none of the subscriber ADSL equipment (e.g. subscriber ADSL modem) in use today is SVC capable. Yet another reason is that the SVC protocol is resource-intensive and brings considerable background load to network elements just keeping signaling channels alive. This background load limits the performance of SVC implementations when the instantaneous signaling load is high (correlated signaling). Multicast video applications are notorious for provoking correlated signaling events—such as during commercial breaks or at the end of a multicast program.
Insufficient memory in data processors of such deployed ATM network nodes is one reason why it would not be feasible or desirable to retrofit IP layer capabilities into deployed ATM network nodes of such networks. Such insufficient memory limits an ability to terminate an IP stack. Insufficient hardware resources for terminating additional IP connections and traffic is another reason why it is not feasible or desirable to retrofit IP layer capabilities into deployed ATM network nodes of such networks.
The cost and time associated with designing IP-based hardware capable of supporting IP-based multicast services in deployed ATM network nodes is one reason why it is often not desirable (e.g. financially practical) to retrofit such IP-based hardware into deployed ATM network nodes. Similarly, the significant cost associated with retrofitting such IP-based hardware into deployed ATM network nodes is another reason why it is often not desirable to retrofit deployed ATM network nodes with IP-based hardware. Still another reason is that a considerable duration of time and considerable coordination is required for retrofitting such IP-based hardware into a potentially large number of deployed ATM network nodes.
Therefore, facilitating IP-based multicasting via a hierarchical network in a manner that overcomes limitations associated with conventional implementations of IP multicasting capabilities and/or with conventional network capabilities is useful.